Recent technological advances combined with market forces have resulted in the creation of new services composed of other services. The term “composite service” is used to describe these new services. Composite service providers pull together a plurality of component services to provide a composite service. Composite services conventionally span several participant organizations. Terms such as “virtual enterprise” and “virtual organization” are conventionally used to describe this type of collection of organizations. A participant organization may provide component services to one or more virtual enterprises. Each component service provider implements a service by executing a process. Implementation of a composite service requires execution of a process that spans multiple organizations. The execution of such multi-organizational processes conventionally involves interaction among participant organizations' computer systems.
By way of example and not limitation, today there are virtual enterprises reselling web search services. Such virtual enterprises receive a query from a user. This query is then used to query selected web search services offered by component service providers of which this virtual enterprise is a client.
Referring to the block diagram of FIG. 1, a group of component service providers' computer systems 20 comprise component service providers 20a and 20b. Component service providers 20a and 20b have respective service implementations 19j and 19k. Service implementations 19j and 19k may be put in communication with composite service providers 10a and 10b of a group of composite service providers' computer systems 10. Each composite service provider 10a and 10b may have one or more client processes 13m to 13n and 13q to 13p, respectively.
Continuing the above-mentioned example, suppose a user of composite service provider 10a places a query for a World Wide Web search. This query invokes client process 13m causing a request to be sent to service implementations 19j and 19k for searching the World Wide Web using respective search engines associated with these services. Results from such searches may then be provided from service implementations 19j and 19k to client process 13m. Hence, in this example, a user executes separate searches on separate search engines of separate service providers from a single query on another separate service provider. In other words, a composite service provider executes a business process which in turn causes component service providers to execute respective business processes.
Accordingly, it should be understood that a component service provider may have several services to offer its clients. Thus, component service providers may have a platform of services available to subscribers or clients. Such services may be invoked through various invocation infrastructures such as Common Object Request Broker Architecture (“CORBA”), Java Remote Method Invocation (“Java RMI”), Hypertext Transport Protocol (“HTTP”), among others. Moreover, this invocation may be manual; for example, a phone call from a composite service provider representative to a component service provider representative.
In the telecommunications field, Competitive Local Exchange Carriers (CLECs) resell local telephone service of Incumbent Local Exchange Carriers (ILECs). Thus, a CLEC may offer services of several ILECs of which it is a client and vise versa. In a CLEC business model, there is interaction between ILEC and CLEC business processes. By way of example and not limitation, a CLEC customer service representative may interact with provisioning ILEC processes to place an order, inquire about an order, or to cancel an order.
Accordingly, with respect to the above-mentioned Internet example and telecommunications example, in order to offer their selection of services, a composite service provider relies on services of its component service providers. Therefore, it is incumbent upon composite service providers as clients of component service providers to enter into agreements to guarantee that service needs are met. Examples of such guaranteed service needs may include maximum response time and minimum throughput. These agreements are referred to hereinafter as Service Level Agreements (SLAs). SLAs also assist component service providers in managing their resources to meet their client's needs. Without such SLAs, a component service provider may be overwhelmed by requests from one client organization, which can affect service level to other clients.
SLAs pertain to services at an application level, as distinguished from end-to-end quality of service (QoS). QoS conventionally pertains to quality parameters of a system infrastructure, or more particularly network performance. A taxonomy of QoS may be found in “Taxonomy of QoS Specifications,” by Bikash Sabata, et al., Proceedings of WORDS '97, February 1997.
Quality objects, which are described in more detail in “Specifying and Measuring Quality of Service in Distributed Object Systems,” by Joseph P. Loyall, et al., Proceedings of ISORC '98, April 1998, facilitate specification monitoring of QoS contracts between clients and service providers. However, this specification monitoring is directed at service implementation details and not invoked functionality. Moreover, in QoS contracts, a client is required to specify resource requirements. However, a client may have limited knowledge of resource usage of an invoked service.
A QoS web server is described in “Supporting Quality of Service in HTTP Servers,” Proceedings of the Seventeenth Annual SIGACT-SIGOPS Symposium on, Principles of Distributed Computing, June 1998. This QoS web server allows allocation of server resources to specific web page requests. System capacity is represented by an estimate of bytes per second served by the server. Thus, issues of guarantees to clients are not addressed.
A product called “SilkMeter” from Segue Software, Inc. of Lexington, Mass., is a software system for supporting usage control in CORBA environments. SilkMeter supposedly controls object usage and access based upon customer-defined usage policies, and provides metering capabilities allowing software owners to monitor usage activity and to bill users accordingly. However, SilkMeter does not support implementation of SLAs.
Hewlett-Packard Company of Palo Alto, Calif., has announced a web QoS strategy. In this announced strategy, website operators may create classes of users with priorities assigned to each class, and more particularly operators may create service classes and allocate capacity to each of them. However, this strategy falls short of providing mechanisms that allow organizations to enter into SLAs. For example, in this strategy, if two organizations are at the same priority level, then it is possible that requests from only one of them will be serviced.
Accordingly, it would be desirable to provide specification and fulfillment thereof for SLAs between organizations. Advantageously, it would be desirable for such SLA specification and fulfillment to be applicable to a variety of services and implementations and to facilitate deployment over existing distributed system infrastructures.